> > You just connect the modems together with a standard telephone line and start your communications software on both machines. Then type "ATA" on. This is excellent!
No it's not. Use a null modem connector instead. It's a lot less hassle. You can buy one at any CompUSA/Computer City store for about $2 or you can make your own.
I used to connect my C64 to my PC using the null modem connection, then I'd type in CTTY COM1: This would redirect all console I/O on the PC to the RS-232 port. It let me use my PC remotely. I wrote a simple XMODEM send program for the PC as well. Using this set-up, I'd browse my PC's directories until I found a C64 program I wanted to download. I'd type SEND <PROGRAMNAME> and start an Xmodem download.
These days I'd rather just use something like 64Net.
----------------------------------
Desterm question
From : csbruce@ccnga.uwaterloo.ca
Perry Eidelbus <pre7874@u.cc.utah.edu> wrote:
>Not having a 128, nor even a copy of Desterm, I have a question concerning it: does it have a hardware flow control (RTS/CTS) option?
No, it only has software (XON/XOFF) flow control.
>He claims that Desterm defaults to RTS/CTS when the flow control is turned off. If Desterm does not have RTS/CTS, as he claims, then that explains why his best cps rates (with null-modem connection and downloading to the buffer) are no more than 720 cps. His explanation is that "The modem-to-motherboard speed is 4800 baud, period" on a 64, and 9600 on a 128; that the SwiftLink's enabling a 64/128 to go past the CIA chips' speed is hogwash ; that the many of you whom I have seen claiming all these super cps rates are outright liars .
What your friend is saying IS hogwash. The modem-to-motherboard speed is more like 8,181,816 bits/sec. The problem with Desterm's speed (or lack thereof) is Software Overhead, including the overhead of whatever downloading protocol is being used. If possible, you should try FX with your friend's setup, and you would see more than 960 cps throughput on a 128.
>(BTW, I would figure that, once a few of you found out CMD's SwiftLink cartridge didn't deliver on its promise of 38.4K bps, you'd not only be complaining here but also getting together and filing a class-action lawsuit against CMD for fraud.)
The SwiftLink does indeed work at 38.4Kbps, because if it were more than 5% off from this figure, it wouldn't work at all. Your friend has much to learn about asynchronous serial communication. In fact, the SwiftLink's main chip is specified to work up to 125Kbps (given the right external serial clock rate).
---------------------------------
modem speed
From : dschmoll@nyx10.cs.du.edu
Hi Tarpon@dsn.Com,
A> 128 has an extra address that the 64 doesn't have...but I think it involves running a wire to a pin somewhere inside the 128...
TC> Yes and no. The three I/O addresses available on the C128 are $D700, $DE00, and $DF00. Unfortunately the three add-ons don't comply so neatly. The REU sits at $DF00. The Swiftlink can use any of the three, depending on software. I use Desterm which only uses $DE00. That leaves the QBB which ALSO uses $DE00. Soooo the solution may be to put a hardware switch on the $DE00 i/o line to the QBB, to bring it high when not in use. That way it shouldn't send any data out when the Swiftlink is addressed. How does that sound????????
Or you can use Dialogue, which supports all three SL addresses. I have a cartidge of my own at $DE00, so I need the $d700 access for SL, and Dialogue gives that to me, in addition to RTS/CTS flow control, better scripts, bigger buffer, and it doesn't need a special beta copy to use my Ramlink!
-----------------------------------
ARGGH! UUxfer help needed ...
From : csbruce@ccnga.uwaterloo.ca
Fuzzy Fox <fox@netcom.com> writes:
>As the author of UUXFER, I know that this is the number one complaint about this program [ that it will accept its input only in ASCII ]. It is a pretty stupid problem, and in fact, it could be easily fixed. However, I'm told that ACE is a better program anyway, so I'm not sure why people still use UUXFER. UUXFER is missing a number of features, such as decent single-drive support. But the program was really just a hack, tossed together for a specific purpose, and since then I haven't found much use for it, and so my desire to improve it has been small. :)
As the author of ACE, I can tell you that a reason why people would use UUXFER over ACE is that UUXFER is a small, easy-to-use menu-driven standalone program that comes in a single piece. ACE is a much bigger (and more powerful) system and is more difficult to use. Also, if a person had no uudecoding software to start with, the logical thing for him to do would be to acquire the BASIC- language uudecoder program from "comp.binaries.cbm" and type it in (manually or automatically) and use it to uudecode UUXFER.
ACE provides a command-line interface to a number of file utilities, etc., and the command to uudecode files is:
uudecode file ...
The uudecode program will accept its input in either PETSCII or ASCII (with CR-LF, LF, or CR line terminators) and automatically detect which is being used (from the "begin" line). Multiple uuencoded files can be extracted from a single input file, and extracted data is put into PRG files. The source code for the program is publically available.
Of course, you can do better than using plain uuencoding for transferring your valuable data around... ;-)
>This information is spelled out fairly clearly in the documentation for >UUXFER, but for some reason the documentation never seems to make it as >far as the program does. :)
To quote the documentation for version 1.1 (available from ccnga):
>First of all, I should think that anyone who does Telecomm work on C64's knows the problem of encoding with ASCII and PETASCII. UUXFER will ALWAYS ALWAYS ALWAYS encode its files in ASCII, and *NOT* in PETASCII! This means that when you upload the file, you must specify either ASCII or BINARY file transfer, or at least specify that you are turning translation OFF. I hope this is clear.
> >When decoding files with UUXFER, the program should cope properly if youaccidentally leave translation turned on, but I won't swear to that. It will properly handle end-of-line encodings of all kinds.
I think that the highlighed statement contributes to the confusion. You appear to be saying that UUXFER will accept PETSCII input, and seems to have been proven now that it definitely does not. Would you like me to modify the documentation on ccnga?
The documentation also says:
>If anyone has trouble, just tug my tail and I'll try to help you out. >Have fun!
but doesn't give an e-mail address.
If there's a newer version of the program and documentation, please send it my way (uuencoding is fine... :-) ).
------------------------
Novaterm ==> Lt.Kernal
From: voyager@eskimo.com (Nick Rossi)
Brian Williams <brian.williams@vdim.com> wrote:
>RL[> Does anyone else but me have a problem running Novaterm 9.5 on a Lt.KernaI. Got it to run by turning on the NMI trap but then if you use a 2400baud modem it seems to run too slow, which forces me to us 1200baud. Does anyone know how to fix this?? I tried for two years to get my registered version of Novaterm to work with my Lt.Kernal without any luck at all. I tried booting from a 1541 and using the Lt.K for a second (file storage) drive and couldn't get that to work either. If I remember correctly, after running through the source code of Nterm, some major revisions in the timing had to be redone.
Though I haven't had much experience with the Lt Kernal, if it's timing that needs to be changed, the NMI interrupt timer values can be modified from the Terminal parameters menu.
Perhaps someone can confirm this, but I'm guessing that the Lt Kernal adds some code of its own to the NMI interrupt (I'm guessing this because the drive has an "NMI trap" option). If it's a significant amount of code, it'll affect timing at 2400 baud. If there's more code there, it would mean the timer values should be adjusted downward, since the timers are being reset later than normal.
---------------------------------
VT100 codes
From : Marko.Makela@HUT.FI
"Craig" == Craig Bruce <csbruce@ccnga.uwaterloo.ca> writes:
Craig> What specific VT-100 features do you need that ACEterm doesn't provide in order to use your freenet?
Craig> BTW, does anyone have a full list of ANSI escape codes handy?
MS-Kermit, the only Terminal program with capital T for MS-DOS, has excellent documentation with all escape codes it supports. Get MS-Kermit 3.14 (or newer, if there is one) and read its documentation.
Actually MS-Kermit is the only MS-DOS program I am missing in Linux. The VT100 emulation in the Linux console driver is not complete. It used to make mistakes when deleting lines in an editor I used to use on my now extinct VMS account.
MS-Kermit has support for several different character sets, and it emulates several terminals from Digital VT100 to VT320, even Tektronix graphics terminals are emulated. It also contains a list of the "ANSI" codes used by beemer BBS programs. BTW, why are the codes called ANSI codes? As far as I know, ANSI is the acronym of American National Standards Institute. And the "ANSI codes" are far from standard, they have been changed along the time.
